문서의 임의 삭제는 제재 대상으로, 문서를 삭제하려면 삭제 토론을 진행해야 합니다. 문서 보기문서 삭제토론 멀티코어 프로세서 (문단 편집) ==== 공유 메모리 모델 ==== 모든 코어/스레드가 하나의 메모리 공간을 공유하는 모델이다. 하나의 코어가 메모리에 쓰기 작업을 하려고 하면 먼저 해당 메모리 공간이 쓰기 가능한지(다른 스레드가 이미 작업 중인지)를 알아보고, 만약 사용 가능하다면 해당 메모리 영역에 잠금(lock)을 걸고 쓰기를 한다. 쓰기 작업이 완료되면 잠금을 해제하여 다른 스레드가 사용 가능하게 한다. 위의 예시로 들자면 잠금을 이미지에 걸고, 픽셀의 값을 읽고 쓰기 전까지 다른 스레드가 픽셀을 건드리지 못 하도록 막는 방법이다. 단순히 잠금장치만 추가하고 해당 일을 하는 스레드를 많이 추가하면 되기에 이미 싱글스레드로 구현된 코드를 멀티스레드로 변환하기 쉽다는 장점이 있으나, 잠금 매커니즘이 관리가 까다롭고 성능 병목이 발생한다는 단점이 있다. 예를 들어 어떤 스레드가 잠금을 획득한 상태로 죽어버리거나(데드락), 두 개의 스레드가 경쟁적으로 잠금을 획득하려고 한다거나([[경쟁 상태|레이스 컨디션]]), 서로 상대방의 스레드가 '잠가 놓은' 리소스를 획득하기 위해 무한히 대기하는 경우(스타베이션)가 발생할 수 있다. 또한 잠금을 확인하는 시점에서 모든 스레드가 동기화되어야 하기 때문에 가장 느린 스레드의 속도에 다른 모든 스레드의 속도가 맞춰져 버리는 단점이 있다. 만약에 스레드간 공유되는 자원이 아예 없다면 락 없이 빠른 병렬성을 보장한다. 거대한 배열에 관한 작업들은 CPU 캐싱이 잘 되게 짤 수 있어서 더욱 그렇다. 위의 이미지 예시를 들어보자면 이미지 자체를 하나의 리소스로 보지 말고, 행 하나하나를 리소스로 보고 스레드 개수로 분할할 수도 있을 것이다. 물론 사양표나 테스트를 통해 해당 작업이 Thread-safe인지 반드시 확인해야 한다. 만약 800x600인 이미지를 4개의 스레드로 쪼갠다면 각 스레드가 800x150의 영역을 담당하여 스레드 0이 0~150번째 행, 스레드 1이 150~300을 담당하는 식으로 서로간의 간섭(혹은 메시지 통신) 없이 메모리의 독립적인 부분에 대한 처리를 하게 된다. 이렇게 분할해서 가져가면 스레드가 가져간 이미지 조각들도 결국 연속된 배열이기 때문에 CPU 캐시 미스 거의 없이 빠르게 처리된다. 이러한 연산에 아래 항목 같은 메시지 전달 작업 모델을 이용했다간 꽤 느려질 위험성을 내포한다. 첫 번째 이유는 메시지 큐(통신 채널)를 사용하는 오버헤드이다. 현용 메시지 큐는 락 없이 최대한 빠르게 동작하도록 설계되긴 하지만 어쨌든 큐에 일감을 넣고 빼는 작업 자체도 CPU 클락이 소모된다. 실제 작업 자체가 간단한 수식 작업일 수록 큐 작업의 오버헤드의 비율이 커져서 비효율적이게 된다. 두 번째 이유는 각 스레드는 메시지 큐에서 일감을 메모리 영역에 대한 일관성이 없이 가져가기 때문에 CPU의 캐시 미스가 더 많이 일어나서 느릴 수 있다는 것. 따라서 벡터곱, 행렬곱, 텐서곱과 같은 균일한 배열에 대한 연산의 병렬화 모델은 메모리 공유 모델을 사용한다. [[GPU]]는 공유 메모리 모델을 사용한다. 위에서 언급한 잠금 관리의 '까다로운' 부분은 하드웨어와 드라이버(런타임 라이브러리)에서 어느 정도 관리해주기 때문에 [[CPU]]보다는 편하게 병렬 프로그램을 작성할 수 있다. 마찬가지로, 최선의 성능을 요구하는 시뮬레이션이나 최신 게임 아키텍처에서는 이 방법으로 성능을 최적화한다. 결과적으로, 데이터를 구조화하거나 처리하는 루틴을 만들 때부터 하드웨어적인 구조를 고려해야 하고, 순수하게 추상적으로만 접근할 수 없어 미적으로는 떨어지지만 그만큼 하드웨어에게 기대할 수 있는 효율성을 더 높게 뽑아낼 수 있는 방식이다. 그 대신 같은 공간에 대한 접근을 터놓기 때문에 아래와는 달리 항상 데이터 오염이나 스레드 예외로 인한 크래쉬, 순차 실행 버그 같은 재현하기도 어렵고 찾기도 어려운 버그의 위험성을 감수해야 하기도 하다.저장 버튼을 클릭하면 당신이 기여한 내용을 CC-BY-NC-SA 2.0 KR으로 배포하고,기여한 문서에 대한 하이퍼링크나 URL을 이용하여 저작자 표시를 하는 것으로 충분하다는 데 동의하는 것입니다.이 동의는 철회할 수 없습니다.캡챠저장미리보기